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(54) Method for propagating the fault information in a RPR networic and corresponding RPR 
paclcet 



(57) Described is a method for propagating the fault 
information on a Resilient Paclcet Ring network, wherein 
each Resilient Paclcet Ring network element sends pe- 
riodically a keep-alive message containing the fault In- 
formation to its neighbor elements on both the ringlet 



directions, in order to inform the neighbor elements that 
the network element is working or to propagate the In- 
fomnation about the detected fault. Once that a fault no- 
tification is propagated, every network element has to 
wait some time before undertaking the necessary steps 
in orderto be sure that thefault notification is persistent. 
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Description 

[0001 ] The present invention relates to the field of the 
RPR (Resilient Packet Ring) networks, and more pre- 
cisely to a method for propagating the fault information 
on a RPR network and to the corresponding packet. 
[0002] In IEEE 802.17 RPR (Resilient Packet Ring) a 
new technology is being defined by the IEEE Standard- 
ization Institute, for optimizing the employment of band 
which is available for the transport of packets on ring 
networks, hereunder defined RPR networks, in particu- 
lar in the context of MAN (Metropolitan Area Networks), 
for instance described in the general aspects in the ar- 
ticle "Resilient Packet Rings for Metro Networks", Glo- 
bal Optical Communication, Pages 142-146, authors N. 
Cole, J. Hawkins, M. Green, R. Sharma, K. Vasani, 
available to the public In the Internet web site hUpM 
www.rpralliance.org/. 

[0003] The ringlet technology can be based for in- 
stance upon physical layers of transport SDH, SONET 
or Ethernet, where the packets of the RPR networks are 
physically transported. 

[0004] As illustrated in Fig. 1 , a known RPR network 
is based on a configuration of dual counter rotating ring- 
lets, a clockwise direction inner ringlet, indicated by a 
grey color, and a counter-clockwise direction outer ring- 
let, indicated by a black color. Both the ringlets are used 
to transport data and/or control RPR packets among a 
series of RPR stations. For instance, with reference to 
Fig. 1 , in a series of RPR network elements, from A to R 
[0005] A RPR packet is meant a frame of layer-2 of 
the known stack ISO-OSI or TCP-IP. The RPR control 
packets are designed to carry out the known RPR func- 
tions, the so-called "topology discovery", "protection 
switching" and "bandwidth management" functions. 
[0006] The "topology discovery" function is based on 
a mechanism which allows to each RPR ringlet station 
to identify and localize all the other stations and their 
distances. When an RPR station inserts a new RPR 
packet into the ringlet, it selects the Inner or outer ringlet 
in order to follow the shortest path towards the RPR des- 
tination station, In temris of number of RPR stations to 
be crossed, according to the network topology. 
[0007] The function of "protection switching" allows to 
guarantee the so-called "resiliency", that is the protec- 
tion capacity at RPR packet level, through a reaction 
within a pre-established period of time (50 ms) from a 
fault detection. In case of fault in the RPR network, the 
RPR control packets of the "protection switching" func- 
tion are used to implement an APS type protocol (Auto- 
matic Protection Switching). Both the known "wrapping 
protection" mechanism, that is conceptually similar to 
the known MS-Spring SDH system applied in the RPR 
layer, and "steering protection" mechanism, conceptu- 
ally similar to the known transoceanb MS-SPRING sys- 
tem applied in the RPR level, are supported. 
[0008] The RPR control packets for bandwidth man- 
agement in the RPR ringlet are used to guarantee an 



adequate access to the ringlet among the various RPR 
stations, independently from the physical location in the 
ringlet. 

[0009] The RPR technology allows the spatial re-use 

5 of the band, by supporting the function of "destination 
stripping": namely, a unicast RPR packet is removed 
from the ringlet of the RPR destination station without 
traveling the whole ringlet, thus leaving the remaining 
path available for re-use thereof. On the contrary, the 

10 multicast, or broadcast or unicast RPR packets whose 
RPR destination station is not on that ringlet can be sub- 
jected to the "source stripping", namely they can be re- 
moved from the same RPR source station after having 
traveled through the whole ringlet. A "time to live" pro- 

?5 cedure is also used to avoid that the RPR packets cir- 
culate in the ringlet indefinitely. 
[0010] Even If the fomnat of a RPR packet has not yet 
been standardized in detail, the fomiat of the RPR pack- 
et comprises a header and a payload. The payload con- 

20 tains the data, namely the high level information to be 
transported. The header, on the contraty, requires at 
least the following fields: 

, - Identification address of the RPR destination sta- 
25 tion; 

identification address of the RPR source station; 
frame type, in order to distinguish among the vari- 
ous types of RPR packets of user's data, control or 
other specific RPR frames; 
30 - type of protocol to identify the type of infomnation 
that is transported in the payload; 
"time to live" TTL: maximum number of nodes, 
where the packet can be propagated in the network, 
in order to avoid that the RPR packets circulate in 
the ringlet indefinitely; 

Ringlet ID: it identifies the path of the outer or inner 
ringlet, where the RPR packet Is inserted; 
CoS, in order to identify the class of service for the 
RPR packet, namely its priority. 

[0011] Some protection mechanisms of the RPR 
packets at packet level In the RPR network are known. 

Said protection mechanisms have to intervene in order 
to solve the fault situations in a very short period of time, 
typically 50 ms. 

[0012] There is, therefore, the problem that the fault 
infomriation exchange among the RPR network ele- 
ments has to be partlculariy rapid and effective, in order 
to allow to all the network RPR elements to react imme- 
diately to guarantee the elimination of the fault in a very 
short period of time (50 ms). 

[0013] The object of the present invention is therefore 

to solve the above said problems and to indicate a meth- 
od to propagate the fault information in a RPR network 
which allows to implement a logical information channel 
that is continuous and dedicated to the exchange of fault 
infomnation on both the RPR ringlets. 
[0014] According to the present invention, each RPR 
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network element sends periodically a "keep-alive" mes- 
sage (in the form of a RPR control packet) containing 
the fault Information to the neighbor elements in both 
the ringlet directions. This message has the dual tunc* 
tlon of: 

informing the neighbor elements that the network 
element Is working: in such a way a fault can be 
declared if the "keep-alive" message is not received 
for a certain period of time; 
propagating the fault information regarding the de- 
tected fault. 

[0015] The forwarding of the "keep-alive" message 
comprises a synchronous forwarding of a periodical 
message with a certain fixed timing, usually to regener- 
ate the previous messages and an asynchronous for- 
warding of messages una tantum to report indications 
of a just generated fault. 

[0016] Besides, once that a fault notification is prop- 
agated, every network element has to wait some time 
before undertaking the necessary steps, in order to be 
sure that the fault notification is persistent 
[0017] Anotherobjectof the present invention is to de- 
fine the format of the RPR control packet bringing the 
"keep-alive" message. 

[0018] In order to achieve these objects, the present 
invention relates to a method to propagate the fault in- 
fonnation on a RPR network and the to the correspond- 
ing RPR packet, as better illustrated in the claims, which 
are an integral part of the present description. 
[0019] The method to propagate the fault information 
on a RPR network according to the present invention 
has the main advantage of providing a continuous RPR 
information chan nel. This allows to the RPR network el- 
ements to be rapidly informed about the fault also In the 
case some "keep-alive" protection messages are lost. 
[0020] A second advantage is that the method ac- 
cording to the present invention does not require further 
corrective actions by the algorithm of "topology discov- 
ery" to detect the presence of a fault and its localization. 
[0021] A third advantage is due to the fact that in case 
of two or more contemporaneous faults with different pri- 
orities, no unnecessary "protection switching", due to a 
transitory condition, is implemented thanks to the check- 
ing mechanism of the persistency of the fault indication. 
[0022] Further objects and advantages of the present 
invention will become clear from the following detailed 
description of an embodiment thereof and from the at- 
tached drawings, given by way of a non-limiting exam- 
ple, wherein: 

Figure 1 illustrates the structure of a known RPR 
network, already described above; 
Figure 2 illustrates the information sent in a fault- 
free case, according to the present invention; 
Figure 3 illustrates the information sent in case of a 
single-fault ringlet, the fault resulting in a break of 
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both the routes among the same network elements; 
- • Figure 4 illustrates the infonnation sent in case of a 
two-fault ringlet, each one resulting in a break of 
both the routes among the same network elements; 
5 - Figure 5 illustrates the information sent in case of 
single-fault ringlet and the break of only one route 
in a direction; 

Figure 6 illustrates the information sent in case of 
dual local fault detected by the same network ele- 

io ment; 

Figures 7 and 8 illustrates respectively a time dia- 
gram and an example of inner circuit in a network 
element for the generation of fault information mes- 
sages. 

15 

[0023] Hereunder, there is the description of a method 
to propagate the fault information in a RPR networi< 
which is the subject of the present invention. 
[0024] As already said, a continuous infonnation log- 

20 ical channel is implemented which is dedicated to the 
fault infonnation exchange on both the RPR ringlets. 
[0025] Each RPR network element sends periodically 
a "keep-alive" message containing the fault information 
to the adjacent elements in both the directions of ringlet. 

25 This message has the dual function of: 

informing the neighbor elements that the networic 
element is working: in such a way, a fault-can be 
declared if the "keep-alive" message is not received 
30 for a certain period of time; 

propagating the protection information regarding 
the detected fault. 

[0026] The fonwarding of the "keep-alive" message 
35 comprises a synchronous forwarding of a periodical 
message with a certain fixed timing (for instance one 
signal at each millisecond), usually to regenerate the 
previous messages and an asynchronous fonwarding of 
una-tantum messages to report the just generated fault 
40 indications. 

[0027] A fault is always detected in the incoming di- 
rection and is always considered bi-directional, namely 
if a fault is detected in the incoming direction, also the 
transmission direction of the other ringlet is declared 
45 faulted. 

[0028] It is known that the detection technique of 
faults on the RPR ringlet is well-known and is not the 
subject of the present invention which has the object to 
propagate the fault information on a RPR ringlet. 

so [0029] As hereunder explained In detail with refer- 
ence to Figures 7 and 8, the generic network element 
can be in two situations according to the point of occur- 
ring and/or detecting of fault: in a first case, if the fault 
is detected by the network element itself, the latter gen- 

55 erates immediately (that is with the top priority) a "keep- 
alive" message which forwards the fault information and 
sends It immediately to the neighbor elements In both 
the directions; in a second case, if the fault has been 
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detected by another elpment which has sent a "keep- 
alive" nriessage, the element in question propagates it 
by regenerating It immediately to the neighbor elements 
of the ringlet In the same direction of reception. In such 
a way, the fault detection information is rapidly bi-direc- 
tionally propagated in the ringlet. 
[0030] The type of propagated Information depends 
on the number of faults and the respective priority. In the 
presence of multiple faults, only the fault with the higher 
priority is notified, namely each RPR network element 
regenerates the "keep-alive" message, by taking the de- 
cision about which one of the fault indications Is to be 
conflnned as per the respective priority, as hereunder 
explained. 

[0031] Once that a fault notification is propagated, 
every network element has to wait a certain time (of any 
milliseconds) before taking the necessary steps, in or- 
der to be sure that the fault notification is persistent, that 
is It is not replaced by another fault Indication with a high- 
er priority. 

[0032] After this period of time, the fault is considered 
as persistent: then, the protection switching method of 
data traffic in the RPR ringlet will be established. 
[0033] Each network element controls the incoming 
part of both the ringlets for a direct fault detection. 
[0034] As far as the format of the RPR packet which 
contains the "keep-alive" message is concerned, the 
packet is of the control type and as already said, it is 
sent by the network element in both the outgoing direc- 
tions on two ringlets. 

[0035] The part of header of the "keep-alive" message 
(with reference to the generic format described in the 
Introduction) contains at least the following data in the 
fields that are of interest for the method according to the 
present invention: 

- identification of the RPR destination station: broad- 
cast; 

- Frame type: RPR control packet; 

protocol type: it identifies the protection protocol; 

- "time-to-live" TTL= 1 : the packet is regenerated in 
the next network element; 

CoS: class of service (namely, priority), with subse- 
quent generation and forwarding in the shortest pe- 
riod of time foreseen by the general system (known 
perse) for the generation of the RPR packets. 

[0036] On the contrary, the part of payload of the 
"keep-alive" message contains the following infomia- 
tion: 

MAC address of the RPR networic element which 
detects the fault: this field is placed at logic zero in 
case of absence of faults (as also shown in Fig. 2); 
fault type: also this field is placed at logic zero in 
case of fault absence; 

direction Indicator; it is placed at logic 1 in the Issu- 
ance direction which is opposite to the fault detec- 



tion place (type of KAD message in Fig. 3). and at 
logic 0 in the ringlet direction where the fault is de- 
tected (type of KA message in Fig. 3); this field is 
used to Identify the direction (which of the two ring- 
5 lets) where the fault has occun-ed; also this field is 
placed at logic zero on both the directions in case 
of fault absence. 

[0037] As already said, to each type of fault a priority 
10 is associated. For example, following priorities from bot- 
tom to top in the various types of fault are implemented: 

- no fault; 

- wait-to-restore WTR: it is generated to restore the 
15 fault and indicates the waiting time interval to re- 
store completely the connection after the repairing 
of the fault and when the repair has become stable; 
it is generated in case of restoring after a single 
fault; 

^0 - manual protection switching: it is manually imple- 
mented by the operator; this condition can be elim- 
inated from the network In case of a fault of higher 
priority; 

signal degrade; 
25 - lack of signal: due to a line break (for instance due 
to a fiber cut); 

- forced protection switching: this condition is forced 
by the operator in a persistent manner. 

30 [0038] As already said, in general in the presence of 
multiple faults, only the fault with the highest priority is 
notified (namely regenerated by each network element), 
while the others are rejected; only in the case of con- 
temporary faults of forced switching type and lack of sig- 
nal, these faults can co-exist on the same ringlet, as two 
equal fault indications can be co-existing. 
[0039] Then, in case of multiple faults, all the networi< 
elements which detect the fault directly have to issue a 
"keep-alive" message which contains their MAC ad- 
dress and the fault type. The direction indicator shall be 
placed at logic 1 or 0 as above explained. 
[0040] In case of dual local fault detected by the same 
network element both on one and two adjacent routes 
on both the directions, each fault is signaled only in the 
direction which Is opposite (counter-rotating) to the de- 
tection direction. 

[0041] If for a certain period of time, a network ele- 
ment does not receive the "keep-alive" message from 
the neighbor element, the respective connection is con- 
sidered in the condition of lack of signal, resulting in the 
issue of a corresponding signaling of fault. 
[0042] As already said, in the case of regeneration, 
each networi< element which receives a fault notification 
on a ringlet (in one direction) has to transmit it - by re- 
generating it immediately - to the neighbor element on 
the same ringlet (direction). If the same element which* 
receives a fault notification also detects locally another 
fault, then that element shall transmit the fault notiflca- 
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tion with a higher priority between both the priorities, by 
rejecting the other. If these have the same priority, then 
the elennent shall propagate the fault notification detect- 
ed locally, if the local f a.ult is a forced switching or a lack 
of signal, the local fault Is always propagated. 
[0043] Once that a fault notification is sent, all the 
"keep-alive" nnessages - which have been sent later - 
shall contain that fault notification up to the replacement, 
as above said. This allows for a very fast reaction to the 
possible lost of a protection message. 
[0044] In the Figures from 2 to 5 some examples are 
shown of checking and generating situations of "keep- 
alive" messages. As in the Figure 1 , the two counter- 
rotating ringlets are respectively indicated by the grey 
color (inner ringlet with a clockwise rotation direction) 
and by the black color (outer ringlet with the counter- 
clockwise rotation direction). Furthermore, in the Fig- 
ures the contents of the message payload Is shown. 
[0045] Fig. 2 shows the information sent in case of no 
fault: on both the ringlets, the various network elements 
generate the messages of periodicaltype with contents 
at logical zero, as above said. 

[0046] Fig. 3 shows the information sent in case of a 
ringlet with a fault and a break of both the routes among 
the same network elements A and B. 
[0047] Both the nodes A and B put their MAC address 
in both the directions, being the elements where the fault 
occurs. Later, the propagation of messages shall follow 
the above said rules, therefore, on the outer ringlet 
(black) the MAC address which is propagating shall be 
B, while on the inner ringlet (grey) it shall be A. As you 
can see, in this way, all the elements are aware of the 
fact that the fault occurred between A and B. In this way, 
the protection switching algorithm will provide a switch- 
ing in order to exclude the direct route between A and 
B and to re-route the traffic on the remaining part be- 
tween B and A. 

[0048] Furthermore, A sets on the logical 1 the direc- 
tion indicator bit in the counter-clockwise issuance di- 
rection (outer ringlet, black) and B sets it In the clockwise 
direction (inner ringlet, grey). 

[0049] In the part relating to the fault type, each ele- 
ment shall regenerate the indication as per the above 
description. 

[0050] Figure 4 shows the information sent in case of 
ringlet with two faults, each fault resulting In a break of 
both the routes among the same network elements, the 
pair A and B, and the pair D and E, respectively. For 
each one of the two pairs, it is valid what said for the 
pairs A and B of Fig. 3. Being interrupted the routes 
which are directed between A and B and between D and 
E, the algorithm of protection switching shall determine 
such a switching to exclude these routes and to re-route 
the traffic on the remaining routes A-F-E and B-C-D. 
[0051] Fig. 5 shows the infonnatton sent in the case 
of a ringlet with a fault and an interruption of traffk: in 
only one link, In only one direction. 
[0052] The faults detected on only one route of the 



pair are considered bi-directional for the data and uni- 
directional for the "keep-alive" messages. 
[0053] With reference to Fig. 5, this means that when 
an element A receives the notification from the element 

5 B and the notification becomes stable, the traffic be- 
tween the elements A and B Is cut, but the notifications 
from B to A are nevertheless transmitted. 
[0054] Therefore, as far as the traffic is concerned, 
this case Is similar to the one of Fig. 3. 

10 [0055] With reference to Fig. 6, as above said, in the 
case of dual local fault detected by the same network 
element both on one and two adjacent links on both the 
directions, each one of the faults is signaled in the only 
direction which is opposite (counter-rotating) to the dl- 

'5 rection of detection. Therefore, for example, if this oc- 
curs to the network element B, the later shall issue in 
the opposite route of the same connection a "keep-alive" 
message containing the fault indication concerning the 
other link of the same direction with MAC address MAC 

20 = B, and the direction indicator at logical 1 . This for both 
the directions. 

[0056] As the fault notifications are immediately trans- 
mitted, each network element has to "integrate" the no- 
tifications received before taking decisions on the data 

25 traffic. This means that the element waits for some time 
(for example some milliseconds) before considering the 
message as final. The integration has to be implement- 
ed after the forwarding of the fault notifications to the 
neighbor elements. 

30 [0057] In case of contemporary faulfs with different 
priorities, it is possible that an unwanted switching is 
performed, owing to the propagation time of transmitted 
messages. This is prevented by putting the integration 
time at least equal to the roundtrip time of a message 

35 on the whole ringlet. 

[0058] With reference to Figures 7 and 8, the method 
for the generation of "keep-alive" messages in the case 
of connection between the elements A and B (Fig. 1) will 
be now explained in detail. 

40 [0059] Each network element generates periodically, 
through a PER block containing a timer, a "keep-alive" 
message, which, as already said, is sent to both the 
neighbor elements (black and grey arrows in Fig. 8) ei- 
ther on both the transmission directions or on the only 

45 direction where it has been received, according to the 
detection place of fault. The message Is composed ac- 
cording to the definition of the respective above de- 
scribed fields. 

[0060] Even if said periodicity is usually equal in all 
50 the elements (for instance, 1 ms), the respective phase 
is not correlated, therefore, each element shall have an 
own instant for the generation of message Independent- 
ly from the other elements. Said message is at logical 
zero under conditions of fault absence: in Fig. 7 this cor- 
55 responds to the initial condition OK1 outgoing from A 
and B (Out A, Out B), and then also at the inlet of B (In B). 
[0061] Let's suppose that at a certain instant, the el- 
ement A detects a fault shown by its Inner block RIL: 
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said fault signaling can originate from either another 
RPR network element through a "keep-alive" nnessage, 
or from the inside of the same element, for Instance gen- 
erated by the physical transport layer (SDH), or directly 
detected as signal absence or absence of "keep-alive" 
message. 

[0062] The fault signal SET outgoing from RIL deter- 
mines the generation by the block ASY, which is within 
A, of a "keep-alive" message F of asynchronous type 
(una-tantum) which shows the fault indication; this mes- 
sage F is immediately sent to the outlet of A (Out A), for 
instance the one towards B, with the top priority. B re- 
ceives it (in B) and regenerates it immediately towards 
the outlet (Out B). 

[0063] Also this "keep-alive" message, as already 
said, is sent either on both the transmission directions 
towards the both adjacent elements (black and grey ar- 
rows In Fig. 8) or only on the direction of receiving, ac- 
cording to the place of fault detection. 
[0064] Starting from this instant, each message out- 
going from the PER block (at the outlets both of A and 
B), periodically sent, shows also said fault condition F 
received from ASY. In otherwords, ASY forces the mes- 
sage F into PER. This is valid till the fault condition at 
the outlet of RIL remains; its disappearance is consid- 
ered as a reset RES for the block PER which restores 
the generation of a periodteal "keep-alive" message at 
logical zero (absence of faults), 0K2 in fig. 7, which is 
re-propagated on the ringlets as above described. 
[0065] The block RIL can detect the origin of the fault 
signaling, whether within the network element or outside 
it, at another element and to control the blocks PER and 
ASY in order to send the "keep-alive" message in only 
one direction or on both the directions. 
[0066] From the above said description, the man 
skilled in the art can, without giving other explanations, 
obtain all the necessary information for Implementing 
the method to propagate the fault information on a RPR 
network, which is the subject of the present invention, 
and also the generation of the respective RPR packets 
and their circulation in the network, by utilizing also the 
common general acknowledge of the already known 
RPR transport techniques. 



Claims 

1. Method for propagating a fault information in a Re- 
silient Packet Ring telecommunication network, the 
network comprising a number of Resilient Packet 
Ring network elements (A, ... F) interconnected by 
links and forming two counter-rotating ringlets, 
wherein packets circulate in two opposite direc- 
tions, characterized in that a continuous logical in- 
formation channel is implemented, the channel be- 
ing dedicated to the fault information exchange on 
both the Resilient Packet Ring ringlets, wherein 
each Resilient Packet Ring network element sends 



keep-alive messages containing the fault informa- 
'tion to the adjacent elements in the network. 

2. Method according to claim 1 , characterized in that 

5 the step of sending keep-alive messages compris- 
es a synchronous forwarding of periodical messag- 
es, and an asynchronous fonwarding of una-tantum 
messages to report the just generated fault indica- 
tions, wherein said rhessages have the top priority. 

10 

3. Method according to claim 2, characterized in 
that, for each network element: 

if a fault is detected by the network element It- 
'5 self, the latter issues a keep-alive message 

which is sent to the ringlet adjacent elements 
in both the directions; 

If a fault has been detected by another element 
which has sent a keep-alive message, said el- 
ement propagates it by regenerating it to the 
further elements of the ringlet in the same di- 
rection of receiving. 

4. Method according to claim 1 , characterized in that 
25 each RPR network element which receives a keep- 
alive message containing fault infomriation, trans- 
mits it by Immediately regenerating it; 

said faults have different priorities, 

in case wherein said element detects locally anoth- 

30 er fault, it will transmit the fault information having 
the higher priority and discard the other, 
if these have the same priority, then the element will 
propagate the fault notification locally detected, and 
said fault infomnation is sent also in the next mes- 

35 sages up to the replacement thereof either by a 
higher priority fault indication or by an indication of 
fault repaired. 

5. Method according to claim 4, characterized in that 
40 each Resilient Packet Ring network element which 

receives a fault information waits for acertain period 
of time before considering the message as final, in 
order to be sure that the fault notification is persist- 
ent and not replaced by another fault indication with 
higher priority. 

6. Method according to claim 5, characterized in that 

a Resilient Packet Ring networi< element which de- 
tects a fault indication regarding an incoming direc- 
50 tion on a ringlet, considers also the parallel direction 
outgoing from the other ringlet as faulted. 

7. Method as claimed in whichever of the preceding 
claims, characterized In that said keep-alive mes- 

55 sages are sent under the form of RPR control pack- 
ets comprising a header and a payload, wherein 
each packet contains at least the following informa- 
tion: 
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a) in the header: 

identification of the destination RPR net- 
work element: broadcast type; type of pro- 
tection protocol; ^ 
regenerated packet in the next network el- 
ement ("time-to-live" TTL = 1); 
class of service (CoS) or top priority; 

b) in the payload: 

MAC address of the RPR network element 
which detects the fault; type of fault; 
direction indicator wherein the fault has oc- 
curred. 

8. Method according to claim 7, characterized in 
that, In case of absence of faults, said MAG address 
and said type of fault are set to logical zero; and 
wherein said direction indicator: is set to logical one 20 
in the issuance direction which is opposite to the 
fault detection direction, and to logical 0 in the ring- 
let direction where the fault is detected; further- 
more, it is set to logical zero on both the directions 

in case of fault absence. 

9. Method according to claim 4, characterized in that 
in the case of dual local fault detected by the net- 
work element itself, both on one and two adjacent 

links on both the directions, each fault is signaled 30 
in the only direction which is opposite (counter-ro- 
tating) the one of detection. 

10. Packet RPR (Resilient Packet Ring) telecommuni- 
cations network comprising means for implement- 35 
ing the method for the propagation of fault Infomna- 
tion In a RPR network and corresponding RPR 
packet as claimed In any of the preceding claims. 

40 



45 



50 



55 
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Fig, 3 
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Fig. 5 
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